Transportation Information Systems and Methods

ABSTRACT

Transportation information systems and methods are disclosed, which facilitate the use of transportation, including trip planning. An exemplary method includes receiving user data associated with public transportation usage. The exemplary method also includes receiving public transportation data including real-time public transportation data. The exemplary method further includes generating scheduling information based on the user data and real-time public transportation data.

CROSS REFERENCE TO RELATED APPLICATIONS

The present application claims the benefit of U.S. Provisional PatentApplication No. 61/381,361, filed on Sep. 9, 2010, entitled“Transportation Information Systems and Methods” by Gontmakher et al.,which is incorporated herein by reference in its entirety.

FIELD

This specification generally relates to transportation information andapplications thereof.

BACKGROUND

Transportation information can be used for planning trips. For example,a user can refer to a published route schedule of a transportationsystem when determining which route to use. Determining which route totake, however, can be challenging for users of transportation systems,for example, when two users try to coordinate with each other to meetusing a transportation system. Schedules of transportation systems areoften inaccurate compared to actual transportation system performance.Furthermore, transportation systems can fail to alert the user tochanges, interruptions, or other situations that affect a planned trip.

BRIEF SUMMARY

Embodiments of this description generally relate to transportationinformation, and applications thereof. Methods, systems, and techniquesfor providing transportation information are provided. In general, oneaspect of the subject matter described in this specification may beembodied in a method for providing transportation information. Anexemplary method for providing transportation information includes theactions of receiving user data associated with public transportationusage. The exemplary method also includes receiving publictransportation data. The exemplary method further includes generatingscheduling information based on the user data and public transportationdata.

Another exemplary method for providing transportation informationincludes generating first scheduling information for a first user basedon first user data, public transportation data, a first startinglocation, and a first destination location. The exemplary method alsoincludes determining whether a second user starting from a secondstarting location different from the first starting location would liketo join the first user. The exemplary method further includes generatingsecond scheduling information for the second user to meet the first useren route based on second user data, the public transportation data, thesecond starting location, real-time location information for the firstuser, and a second destination location. The exemplary method alsoincludes generating an alert for the second user following the secondscheduling information to depart from the second starting location at aspecified time to meet the first user following the first schedulinginformation.

Another exemplary method for providing transportation informationincludes receiving public transportation data including real-timevehicle location information and at least one of historical vehiclelocation information and scheduled vehicle location information. Theexemplary method also includes generating a schedule degradation modebased on a deviation of real-time vehicle location information from atleast one of historical vehicle location information and scheduledvehicle location information. The exemplary method also includesgenerating scheduling information for a user based on a deviation ofreal-time vehicle location information from at least one of historicalvehicle location information and scheduled vehicle location information.The scheduling information includes an indication of the scheduledegradation mode. The scheduling information can be changedsubstantially based on the schedule degradation mode.

Another exemplary method for providing transportation informationincludes receiving user data associated with public transportation usageincluding at least one of user locations, user movements, usertransportation queries, user routes, and user vehicles. The exemplarymethod also includes receiving public transportation data includingroutes available to a user. The exemplary method further includesgenerating a user profile for the user based on the user data and thepublic transportation data. The user profile includes automaticallygenerated route suggestions for the user.

Other embodiments of these aspects include corresponding systems,apparatuses, and computer program products configured to perform theactions of these methods, encoded on computer storage devices.

BRIEF DESCRIPTION OF THE DRAWINGS/FIGURES

Further embodiments, features, and advantages as well as the structureand operation of the various embodiments are described in detail belowwith reference to the accompanying drawings. In the drawings, likereference numbers may indicate identical or functionally similarelements.

FIG. 1 is a diagram of an exemplary transportation information system,in accordance with an embodiment.

FIG. 2 is a diagram of an exemplary transportation information systemincluding a profile creator, in accordance with an embodiment.

FIG. 3 is a diagram of an exemplary transportation information systemincluding a public transportation analyzer and a rider analyzer, inaccordance with an embodiment.

FIG. 4 is a diagram of an exemplary transportation information systemincluding a routing engine and a degradation mode, in accordance with anembodiment.

FIG. 5 is a diagram of an exemplary transportation information systemincluding a rider analyzer, a routing engine, and updated schedulinginformation, in accordance with an embodiment.

FIG. 6 is a diagram of an exemplary transportation information systemincluding an alert generator and an alert, in accordance with anembodiment.

FIG. 7 is a flowchart of a method for providing transportationinformation, in accordance with an embodiment.

FIG. 8 is a flowchart of another method for providing transportationinformation, in accordance with an embodiment.

FIG. 9 is a flowchart of another method for providing transportationinformation, in accordance with an embodiment.

FIG. 10 is a flowchart of another method for providing transportationinformation, in accordance with an embodiment.

FIG. 11 is a diagram of an application of an exemplary transportationinformation system, in accordance with an embodiment.

FIG. 12 is a diagram of an application of an exemplary transportationinformation system, in accordance with an embodiment.

FIG. 13 is a diagram of an application of an exemplary transportationinformation system, in accordance with an embodiment.

Embodiments are described with reference to the accompanying drawings.

The drawing in which an element first appears is typically indicated bythe leftmost digit or digits in the corresponding reference number. Thedrawings are not necessarily drawn to scale.

DETAILED DESCRIPTION

I. Overview

II. System Architecture

III. User Profile

IV. Degradation Modes

V. Determining Relevant Routes for a User

VI. Adapting to User Behavior

VII. Alerts

VIII. Exemplary Methods

IX. Routing

X. Additional Advantages Including Real-Time Applications

XI. Further Examples

XII. Conclusion

I. Overview

Embodiments of this disclosure relate to transportation informationsystems and methods, and applications thereof. Users may need helpnavigating transportation systems. In one embodiment, user dataassociated with public transportation usage is received. Publictransportation data including real-time public transportation data isreceived. Scheduling information is generated based on the user data andreal-time public transportation data.

In the detailed description that follows, references to “oneembodiment”, “an embodiment”, “an example embodiment”, etc., indicatethat the embodiment described may include a particular feature,structure, or characteristic, but every embodiment may not necessarilyinclude the particular feature, structure, or characteristic. Moreover,such phrases are not necessarily referring to the same embodiment.Further, when a particular feature, structure, or characteristic isdescribed in connection with an embodiment, it is submitted that it iswithin the knowledge of one skilled in the art to effect such feature,structure, or characteristic in connection with other embodimentswhether or not explicitly described.

II. System Architecture

FIG. 1 is a diagram of an exemplary transportation information system100, in accordance with an embodiment. Transportation information system100 includes an analyzer 110. Analyzer 110 includes a profile creator112, public transportation analyzer 114, rider analyzer 116, routingengine 118, alert generator 120, and report generator 122. Analyzer 110can receive user data 130, public transportation data 140, and otherinputs. Analyzer 110 can provide user profile 150, schedulinginformation 160, degradation mode 170, and other outputs. Reportgenerator 122 can generate reports of the scheduling information.

Analyzer 110 is in communication with network(s) 180, which is incommunication with computing device(s) 190, third party service(s) 194,mapping service(s) 198, and other interfaces. Network(s) 180 can includethe Internet and one or more networks including local area networks(LANs), wide area networks (WANs), and wireless networks. Computingdevice(s) 190 can include personal computers, mobile computers includingcellular telephones, tablet computing devices, and other devices capableof exchanging information. Third party service(s) 194 can includedevelopers and aggregators. Analyzer 110 can interface with variousservices, including but not limited to Google Goggles, Google Latitude,Google Calendar, Google Earth, Android, Google Mobile Maps, Google VoiceSearch, Google Search, Google Maps, and Google Translate. Analyzer 110can also interface with various transit systems, including but notlimited to bus systems, railway systems, subway systems, airlinesystems, boating systems, traffic infrastructure systems, and alertsystems.

Components of transportation information system 100 (e.g., profilecreator 112, routing engine 118, alert generator 120, and reportgenerator 122) may be implemented as software, hardware, firmware, orany combination thereof. Components of transportation information system100 may also be implemented as computer-readable code executed on one ormore computing devices capable of carrying out the functionalitydescribed herein. Such a computing device can include, but is notlimited to, a personal computer, mobile device such as a mobile phone,workstation, embedded system, game console, television, set-top box, orany other computing device. Further, a computing device can include, butis not limited to, a device having a processor and memory for executingand storing instructions. Software may include one or more applicationsand an operating system. Hardware can include, but is not limited to, aprocessor, memory and graphical user interface display. The computingdevice may also have multiple processors and multiple shared or separatememory components. For example, the computing device may be a clusteredcomputing environment or server farm.

Note that in alternative embodiments, any subset of the components shownin FIG. 1 may in fact be embodied as a single component. For example,the functionalities of rider analyzer 116 and routing engine 118 may becombined in a single device or module. Other combinations of thefunctional components of FIG. 1 are also possible, as would be known toa person of skill in the art. Further, analyzer 110 may have more orless than the components shown in FIG. 1.

III. User Profile

FIG. 2 is a diagram of an exemplary transportation information system200 including a profile creator 112, in accordance with an embodiment.Profile creator 112 can receive user data 130 as input, and can provideuser profile 150 as output. User data 130 can include user locations,user movements, user transportation queries, user routes, user vehicles,and other user data related to transportation. Times and localities forthe user data can also be provided to profile creator 112.

User data 130 can also include user location data 210. User locationdata 210 enables a user's location to be determined through varioustechniques. User location data 210 can include browser-based locationinformation, mobile computing device location information, publictransportation services location data, user check-in to publictransportation vehicles (e.g., swiping an access card at avehicle-mounted reader), user association with public transportationentry ports (e.g., swiping an access card at a station turnstile), useraccess to a routing search engine or public transportation information,and user-provided locations such as a home address or business address.

User location data 210 and user data 130 can be used by profile creator112 to create user profile 150. User profile 150 can be createdautomatically based on user data 130 and user location data 210. Profilecreator 112 can collect known route segments the rider has taken, andbuild user profile 150. For example, profile creator 112 can collectknown route segments a rider has taken from GPS tracks, vehicle/tripcheck-ins, timing of boarding and alighting from public transportation,and usage of other public transportation applications.

In one embodiment, a transportation information system can learn fromuser locations, movements, queries, preferred/most used routes, trips,vehicles, and other user data 130, and can thereby provide users withimproved transportation information.

IV. Degradation Modes

FIG. 3 is a diagram of an exemplary transportation information system300 including public transportation analyzer 114 and rider analyzer 116,in accordance with an embodiment. Public transportation analyzer 114 canreceive public transportation data 140 as input, and provide degradationmode 170 as output. Rider analyzer 116 can receive, as input, publictransportation data 140, user data 130, user profile 150, and outputfrom public transportation analyzer 114. Rider analyzer 116 can provide,as output, updated user profile 310 and relevant public transportationroute segments 312. Relevant public transportation route segments 312can be based on updated user profile 310.

Public transportation analyzer 114 can analyze historical, current(including real-time), scheduled, and other types of publictransportation data 140. In one example, public transportation data 140includes real-time public transportation vehicle location information,public transportation scheduling information, historical publictransportation vehicle location information, public transportationstations, public transportation lines, and public transportationavailable trips. Public transportation data 140 can include any relevantinformation that enables public transportation analyzer 114 to preparean analysis.

Public transportation systems can have a schedule which determines atwhat times public transportation vehicles pass certain stations or timepoints corresponding to the schedule. As long as the transit networkoperates according to the schedule, very precise plans for trip requestscan be generated. Even if vehicles deviate slightly from the schedule,precise routing can provide useful information to users because thevehicles should deviate only slightly from the precise plans.

A service provided by a transit network can become degraded even beyondslight deviations from the schedule. Degradation, including even slightdeviations, can be detected by public transportation analyzer 114 andindicated by degradation mode 170. In one embodiment, schedulinginformation is substantially changed based on degradation mode 170.

Degradation of public transportation systems can occur in manysituations. For example, during rush hour, buses may not keep up withtheir schedule because of general traffic or congestion. Buses servingthe same line might overtake each other and affect the times at whichthey arrive, depart, and service each bus stop or reach a point in theschedule. Unpredictable changes that affect the transportation systemcan cause the operation of the transportation system to departsignificantly from the schedule, so that the schedule can no longer berelied upon. Such unpredictable changes can include accidents,rerouting, cancellations, extra trips, dispatcher intervention, andother unpredictable changes. Furthermore, changes in one portion of thetransportation system can affect other portions of the transportationsystem, sometimes in ways that are not immediately apparent to users oreven operators.

Different degradation modes can be used to enable different handling byembodiments of a transportation information system. Degradation modescan apply to an entire public transportation system/transit network, orpart of the public transportation system/transit network.

A degradation mode can indicate that service is running according toschedule with high precision. Another degradation mode can indicate thatservice is not running according to schedule, with significantdeviations. Yet another degradation mode can indicate that service isnot running according to schedule at all, but an approximate frequencyof vehicles is still maintained. An approximate frequency of vehiclesmay correspond to normal operating mode for some agencies. Yet anotherdegradation mode can indicate that service is not running according toeither schedule or frequencies (for example, no bus serving a stationfor 30 minutes where normally a bus serves that station every 10minutes).

In one embodiment, various services can be provided depending on thedegradation mode. The way routes are computed can be changed, e.g., theway that scheduling information is determined and provided. For example,when routes are computed according to a schedule and the next bus passesthe first station in 10 minutes, that 10 minutes is used as a basis forstarting the route. In one embodiment, if a transportation informationsystem detects that the transit network is now operating in adegradation mode associated with frequency-only, the route can bestarted from the current time, and vehicle frequency used as an expectedwaiting time.

In one embodiment, a transportation information system can change theway routes (including requested scheduling information 160) aredisplayed, corresponding to the degradation mode. In one example, aroute can be displayed to indicate that timing is imprecisecorresponding to the degradation mode, and that scheduling information160 is computed based on approximate, and not precise, scheduling times.In one embodiment, a transportation information system can compute anddisplay confidence intervals in the computed timings associated withscheduling information 160.

In one embodiment, users can be alerted in association with adegradation mode. A transit network may supply alerts for servicedisruptions, but such alerts may not enable a user to predict whataffect the alert will have on a planned trip. In one embodiment, atransportation information system can use such alerts to inform a userof an event, and can also derive and show an alert independently fromthe transit network alerts (separate from or in addition to showingroutes in a different way). Alerts may be generated and shown in thefollowing contexts: i) when the user views the map in public transportmode (or just zoomed in enough), ii) when the user views schedules of astation or a line, iii) when the user views a computed route, and iv)while the user is following a previously computed route. Additionaltechniques and combinations of generating and showing alerts arepossible.

Various techniques can be used to compute degradation mode 170. In oneembodiment, public transportation analyzer 114 can compare real-timevehicle positions or arrival estimations with the schedule. In anotherembodiment, public transportation analyzer 114 can compare real-timevehicle positions or arrival estimations with historical data for asimilar period. The historical data can be collected over time from atransit network if available, or can be collected over time usingembodiments of the transportation information system. Such comparisonscan enable embodiments to compute how unusual is the current situation,e.g., degradation mode 170.

Generating an alert can be dependent on schedule adherence. For example,for Zurich, where schedule adherence is high, alerts regardingdegradation mode 170 can be generated when a train is over one minutelate (and a severe alert if the train is over 10 minutes late). Incontrast, for a bus system somewhere else where schedule adherence isnot as high, the corresponding values for generating alerts may be 15minutes or an hour, adjustable depending on such factors as the scheduleadherence, historical performance, and real-time data for the particulartransit network.

V. Determining Relevant Routes for a User

Referring again to the embodiment illustrated in FIG. 3, rider analyzer116 can receive as input public transportation data 140, user data 130,user profile 150, and output from public transportation analyzer 114.Rider analyzer 116 can then analyze the inputs and generate an updateduser profile 310, including relevant public transportation routesegments 312.

Users (e.g., public transportation riders) over time can develop somepublic transportation usage patterns that may be temporal or local.Temporal travel patterns of a user may include the user traveling at thesame time of day. Locality travel patterns of a user may include theuser traveling with the same service, though not necessarily the sametrip every day. In one embodiment, rider analyzer 116 can identify acluster of route segments in a transit network that is relevant to auser, and generate an updated user profile 310 that assigns those routesegments to updated user profile 310. In one example, locations andtimes of day can be assigned to a user profile. In one embodiment, auser's relevant route segments can be automatically detected based onthe user's user profile 150.

Updated user profile 310 can be generated based on detecting features ofthe transit network local to the user. The local transit network can besegmented and clustered into used and unused services for that user.Clustering can be done locally (similar routes, as defined by vehicletype, route, etc., up to mild variations, including different times ofday). Clustering can also be done temporally (services running along asimilar route, or sharing similar start and end points, at similar timesof the day over time). The route segment clusters can then be used toidentify relevant public transportation route segments 312 and otherinformation that may affect the user's trip. Relevant publictransportation route segments 312 and other information can be providedto the user. For example, relevant public transportation route segments312 may be displayed on a screen of a computing device for the user.Relevant public transportation route segments 312 and other informationcan be stored in updated user profile 310.

In some embodiments, using updated user profile 310 can provide variousapplications. Personalized nearby public transportation information canbe enabled for the user. For example, in one embodiment, nearbystations, lines, and trips can be ranked according to the user'sprofile.

In some embodiments, public transportation service alerts can bepersonalized to a user based on deduced commute routes, regardless of anexact time of travel. Alert severity can be customized based on animportance to the user. For example, a mild delay in a station outsideof the user's area may still lead to severe delays on a service relevantto the user. Accordingly, the user is alerted even though it may nothave been apparent to the user that the mild delay in a station outsideof the user's area would have led to a delay that affected the user.

In one embodiment, routes that the user is not taking can be suggestedto the user by analyzing that such routes fit the user's profile orprovide benefits. Users may not always know all the transit systemsaround them or know the fastest route using a transit system. In oneexample, a suggested route may be faster than the user's currentlychosen route. Other benefits may be based on other criteria, such asproviding routes having fewer connections, using a rail transportationsystem instead of a bus, and so on.

In one embodiment, an alert is generated when a user is taking a vehiclethat does not fit the user's profile, or is otherwise an unexpectedselection for the user based on user profile 150, updated user profile310, or both (e.g., going on a bus that differs from the user's usualcommute at a time when the user is expected to take another action suchas going home).

In one embodiment, a transit system can be personalized for a user byproviding known trips for the user (analyzed from user profile 150,updated user profile 310, or both). In another embodiment, atransportation information system can enable the user to comparepreviously taken routes to newly suggested routes.

In one embodiment, a transportation information system can provideuseful defaults for user routing queries. For example, rider analyzer116 may take note of queries entered by a user and a trip that the userultimately decides to take. This data may be used to offer suggestionsto other users when searching similar trips. User profile 150, updateduser profile 310, or both can enable embodiments to find a reasonableset of from and to locations and relevant times of day for the user.

In one embodiment, user preferences for routing parameters can belearned. In one example, rider analyzer 116 can determine appropriateconnection time buffers, walking speeds, vehicle type preferences,walking distance preferences, and other user preferences by automaticanalysis of various data. In another example, user preferences can bemanually configured. In some embodiments, the use of a user'stransportation information may be provided as an opt-in service where auser may indicate in advance his or her approval of use of the user'stransportation information.

FIG. 4 is a diagram of an exemplary transportation information system400 including routing engine 118 and degradation mode 170, in accordancewith an embodiment.

Routing engine 118 can receive, as input, user data 130, publictransportation data 140, user profile 150, and degradation mode 170.Accordingly, routing engine 118 can provide scheduling information 160as output, including an indication of degradation mode 170. For example,scheduling information 160 can include explicit mention of thedegradation mode and the level of deviation from the schedule.Scheduling information 160 can also be presented in a way that visuallyrepresents the level of degradation or deviation from the schedule. Forexample, a circle centered on a destination can approximate a range ofarrival times using a corresponding diameter, in contrast to a point.Routing engine 118 may display the generated scheduling information to auser (e.g., on the user's computing device). Based on degradation mode170, routing engine 118 may alter an appearance of schedulinginformation 160.

VI. Adapting to User Behavior

FIG. 5 is a diagram of an exemplary transportation information system500 including rider analyzer 116, routing engine 118, and updatedscheduling information 520, in accordance with an embodiment. Rideranalyzer 116 can receive, as input, user behavior 510 and schedulinginformation 160. Rider analyzer 116 can detect discrepancies betweenrouting suggestions, provided in scheduling information 160, and routesusers actually take, provided in user behavior 510. Rider analyzer 116can provide the analysis results to routing engine 118. Routing engine118 can use the output from rider analyzer 116 to generate updatedscheduling information 520.

In one embodiment, a transportation information system can adapt to userpreferences, and provide popular routes that are more consistent withuser behavior 510. In another embodiment, a transportation informationsystem can provide an indication that scheduling information has beenupdated, e.g., when generating updated scheduling information 520. Theuser can be asked to verify whether updated scheduling information 520is desirable.

VII. Alerts

FIG. 6 is a diagram of an exemplary transportation information system600 including alert generator 120 and alert 610, in accordance with anembodiment. Alert generator 120 can receive, as input, degradation mode170, user behavior 510, user data 130, public transportation data 140,user profile 150, scheduling information 160, and vehicle identification620.

Vehicle identification 620 can be determined using various techniques.For example, determining which vehicle a user (passenger of theidentified vehicle) is on can involve matching the user's location withreal-time data for the identified vehicle's location. The user'slocation can be provided by a Global Positioning System (GPS) feature onthe user's portable computing device such as, for example, a smartphone.Other location methods are possible, including wireless signaltriangulation. The identified vehicle location can be provided by, forexample, the transit agencies.

In one embodiment, vehicle identification 620, corresponding to theuser's location, can be provided to alert generator 120. Alert generator120 can generate alert 610, which can be used in various applications.Although not illustrated, vehicle identification 620 can be provided tovarious other components of analyzer 110, including rider analyzer 116,routing engine 118, and other components.

In one example, when a train is about to enter a tunnel and the userwill lose GPS location, alert 610 can be used to notify analyzer 110 touse a different method of determining the user's location. In oneembodiment, analyzer 110 can determine a user's location based on aposition of the vehicle the user is in, according to vehicleidentification 620. Position data for the identified vehicle may begathered using a GPS that functions in tunnels, odometer readings thatgive the distance the train has traveled, or other methods. For example,a transit network may use transponders positioned on the tracks toidentify train locations. Even during a detour, the system can determinethat the vehicle will arrive at a specific station, information whichcan be used for locating the vehicle and user. Alert 610 can also beused to notify the user that a different method of location detection isbeing used for the user. A user's GPS can be compared with a vehicle'sGPS to determine that the user is on a particular vehicle. The user canbe “checked in” to that vehicle. The user may also be given the optionof manually “checking in” to a vehicle. The user can send the vehicleinformation to other users who can be kept informed of the user'sprogress via that vehicle's progress.

In one embodiment, alert 610 can be used to provide various informationto the user. In another embodiment, alert 610 can be used to providevarious information to analyzer 110. Alert 610 can warn the user thatthe vehicle the user is on is about to enter an area with no cellularsignal or no GPS signal. This is useful, for example, if the user is onthe phone during a telephone call or using data provided by the cellularsignal or GPS signal. Alert 610 can notify the user that analyzer 110may not be able to provide trip advice while the user is in the tunnelor otherwise without a data signal, GPS signal, or both.

Alert 610 can be used to notify analyzer 110, the user, or both when thevehicle the user is on is about to reach the user's stop. Alert 610 canbe used to alert the user if the user is going to miss a connection on aplanned trip.

Alert 610 can be used to notify other people regarding the user'sstatus. For example, a user's friend who is going to meet the user canbe notified of the user's progress on a trip based on the predictionsanalyzer 110 has for the identified vehicle the user is traveling on.

Alert 610 can provide basic information about the trip the user iscurrently on. For example, analyzer 110 can provide schedulinginformation 160 including a list of upcoming stations and estimatedtimes, similar to that which is often displayed on trams. Alert 610 canprovide notifications of this information to the user, e.g., on theuser's own device such as a mobile computing device.

Alert 610 can provide a warning of problems up ahead along the user'sroute, so that the user can reroute before getting stuck.

VIII. Exemplary Methods

FIG. 7 is a flowchart 700 of a method for providing transportationinformation, in accordance with an embodiment. At a stage 710, user dataassociated with public transportation usage is received. At a stage 720,public transportation data is received. At a stage 730, schedulinginformation is generated based on the user data and the publictransportation data.

FIG. 8 is a flowchart 800 of a method for providing transportationinformation, in accordance with an embodiment. At a stage 810, firstscheduling information is generated for a first user. In one embodiment,routing engine 118 may generate first scheduling information for a firstuser based on first user data, public transportation data, a firststarting location, and a first destination location.

At a stage 820, it is determined that a second user would like to jointhe first user en route. In one embodiment, routing engine 118 maydetermine that a second user starting from a second starting locationdifferent from the first starting location would like to join the firstuser.

At a stage 830, second scheduling information is generated for thesecond user. In one embodiment, routing engine 118 may generate secondscheduling information for a second user to meet the first user based onsecond user data, public transportation data, the second startinglocation, real-time location information for the first user, and asecond destination location.

At a stage 835, it is determined whether it is time for the second userto depart. If it is not time for the second user to depart, the systemwaits at a stage 837 and process flow returns to stage 835. If it istime for the second user to depart, at a stage 840, an alert isgenerated for the second user to depart to join the first user en route.In one embodiment, alert generator 120 generates an alert for the seconduser to depart to join the first user. Alert generator 120 may generatean alert for the second user to depart from a second starting locationat a specified time to meet the first user.

FIG. 9 is a flowchart 900 of a method for providing transportationinformation, in accordance with an embodiment. At a stage 910, publictransportation data is received. The public transportation data mayinclude scheduled vehicle location information and actual vehiclelocation information. At a stage 915, it is determined whether scheduledvehicle location information deviates from actual vehicle locationinformation. If the deviation does not exceed a threshold, at a stage917, scheduling information is generated for the user. If the deviationexceeds a threshold, at a stage 920, a schedule degradation mode isgenerated. At a stage 930, scheduling information including anindication of the schedule degradation mode is generated for the user.

FIG. 10 is a flowchart 1000 of a method for providing transportationinformation, in accordance with an embodiment. At a stage 1010, userdata associated with public transportation usage is received. At a stage1020, public transportation data including routes available to the useris received. At a stage 1030, a user profile including automaticallygenerated route suggestions is generated.

IX. Routing

FIG. 11 is a diagram of an application of an exemplary transportationinformation system, in accordance with an embodiment. Users A 1110 and B1120 agree to meet at a destination 1150, e.g., a restaurant, using atransit system. A 1110 plans his route to destination 1150. A's routefrom origin 1112 to destination 1150 includes portions 1114 and 1116.Along the way, A's vehicle makes stops, including a stop 1130 (e.g., ata station).

A 1110 shares his itinerary with B 1120. B chooses to “join” this trip.A's scheduling information and B's scheduling information can begenerated based on different forms of travel used by A and B (e.g.,their travel preferences).

A begins the trip at origin 1112, and once he boards the vehicle atorigin 1112, the actual times of the vehicles he will catch arecalculated (e.g., based on best approximations of connection times,degradation modes, etc., as determined by analyzer 110).

B 1120 is informed when to begin his trip so that he will meet with A1110 at stop 1130. B's route from origin 1122 to destination 1150includes portions 1124 and 1126. B's vehicle makes a stop at stop 1130.

In one embodiment, a transportation information system instructs B 1120such that B 1120 arrives at stop 1130 in time to catch the vehicle thatA 1110 is using. Therefore, A 1110 and B 1120 meet on the vehicle, andtravel together (for example, along the last leg 1140 of a journey). A1110 and B 1120 proceed to destination 1150 together, and do not have toride separately in portions 1116 and 1126 of the trip. In oneembodiment, a vehicle that A 1110 is riding on that travels along a pathof A's generated scheduling information is identified. The identifiedvehicle and path are included in B's generated scheduling information.

During travel, A 1110 or B 1120 may experience delays or a deviationfrom the original scheduling information. In one embodiment, A'sscheduling information is updated based on real-time transportation dataof B 1120. In another embodiment, B's scheduling information is updatedbased on real-time transportation data of A 1110. For example, if A 1110is delayed and there are multiple stops along B's path, B 1120 maydecide to exit a transportation vehicle that B 1120 is riding on, take acoffee break at a particular stop for a time period, and take adifferent transportation vehicle at a later point in time to join A 1110at stop 1130.

In one embodiment, A 1110 is alerted when real-time transportation dataof B 11120 deviates from the second scheduling information. In anotherembodiment, B 1120 is alerted when real-time transportation data of A1110 deviates from the first scheduling information.

FIG. 12 is a diagram of an application of an exemplary transportationinformation system, in accordance with an embodiment. As illustrated, asystem can choose different routes, and even modify a passenger's routepostfactum, in order to maximize a portion 1250 of the trip that users A1210 and B 1220 spend together. For example, B 1220, if traveling aloneor taking a direct trip, would not typically choose to travel away froma destination 1260. B 1220, however, might choose to go out of his wayif that helped him meet A 1210 sooner and allowed A 1210 and B 1220 tospend more time together on the trip.

In one embodiment, A's scheduling information may be adjusted toincrease a portion of the trip that A 1210 and B 1220 spend together. Inanother embodiment, B's scheduling information may be adjusted toincrease a portion of the trip that A 1210 and B 1220 spend together.For example, a distance of B's generated route that includes the path ofA's generated route is longer than a distance of another route from B'sstarting location to B's destination location. In this embodiment, A1210 and B 1220 spend more time together along the route.

As illustrated, A 1210 departs from origin 1212, proceeds along path1214 to a stop 1230, then along path 1216 to stop 1240, and along path1218 to stop 1260. A 1210 shares his itinerary with B 1220 and B 1220chooses to join A's trip.

B 1220 has an option of traveling a more direct route from origin 1222along path 1223 to stop 1240. B 1220, however, chooses to spend moretime with A 1210 during the trip. In one embodiment, it is determinedthat B 1220 can travel along path 1224 and intercept A 1210 by catchingA's vehicle at stop 1230. In this embodiment, B 1220 can be instructedwhen to depart from origin 1222, and the vehicle in which A 1210 isriding can be identified, so that B 1220 can find A 1210.

Accordingly, for the remainder of trip 1250, A 1210 and B 1220 traveltogether from stop 1230 to stop 1240 and on to destination 1260. Thisavoids A 1210 and B 1220 from having to travel separately along paths1216/1226 and 1218/1228.

FIG. 13 is a diagram of an application of an exemplary transportationinformation system, in accordance with an embodiment. Users A 1310 and B1320 want to meet at a common location, timed to arrive approximatelysimultaneously at destination 1340. A 1310 is departing from origin1312, and B 1320 is departing from origin 1322.

The system can determine that A's path will take more time, and generatescheduling instructions for A 1310 to depart before B 1320 departs. A1310 travels along path 1314 to stop 1330, then along path 1316 todestination 1340. While A 1310 is traveling, the system determines whenB 1320 should depart from origin 1322. B 1320 then departs and travelsalong path 1324. B 1320 arrives at destination 1340 approximately at thesame time as A 1310, meeting A 1310 at destination 1340.

If A's trip changes or is rerouted for some reason, then the system cannotify B 1320, reroute A 1310, reroute B 1320, or a combination ofthese. For example, if A 1310 misses a connection, B 1320 is notifiedand can be rerouted to meet A 1310. The system may determine that B 1320should leave at a later time. Similarly, A 1310 can be notified ofchanges in B's trip. For example, A 1310 can be notified that B 1320 haschosen to join A's trip, or that B 1320 is expected to meet A 1310 at acertain point. If B's trip changes, A 1310 can be updated and decidewhether to be rerouted.

Embodiments illustrated in FIGS. 11-14 can be used between multiplevehicle types, including between public transit and personaltransportation. If A 1310 is meeting B 1320 simultaneously in FIG. 13,the system can track when A 1310 gets on the train at origin 1312, forexample. The system will calculate when B 1320 should get in his car,for example, so that B 1320 arrives at destination 1340 at approximatelythe same time that A 1310 arrives at destination 1340. This can beextended to any form of traveling such as walking, bicycling, cardriving, bus systems, train systems, and any combination of these forrouting or meeting en route.

X. Additional Advantages Including Real-Time Applications

In one embodiment, riders can be alerted as to the capacity of variousvehicles. In one example, the system can notify a user that a bus ortrain car is full. In this example, the user can plan to catch the nextbus or train car that is not as crowded. In one embodiment, atransportation information system can determine such information basedon information from a transit system, user behavior 510, and other datathat can identify passenger load in a vehicle.

In one embodiment, a transportation information system can notify usersof various features of a transit network/system. For example,embodiments can determine that it is raining, and therefore can advise auser which stops have a shelter to avoid the rain. For example, thesystem can alert the user to get off one stop early, so that the usercan wait under a shelter at the earlier stop.

Embodiments can be used for real-time information in publictransportation systems. Users, developers, aggregators, and others canuse the information in various ways. Developers/a developer feed canquery a subset of the data. An example query can be “arrivals at stationX in the next 10 minutes.” Embodiments can provide information withlittle need to cross reference, and can synthesize many standards acrossa variety of transportation systems. A snapshot of all the data can beprovided, e.g., for an aggregator/aggregator feed. The data can beprovided in a consistent format. Data formats can be optimized foraggregation, including a reference to a static schedule and incrementalupdates.

Real-time data can be useful for alerting users if a vehicle is late orotherwise deviating from a schedule, rerouting a trip, or knowing thatan event affects a user's trip. For example, embodiments of atransportation information system can determine whether parts of apublic transit system route lack cellular or GPS signals and offer auser the choice of choosing another route with more reliable wirelesssignals. Embodiments can determine signal dead-spots where there are norequests coming from mobile networks. In high-usage areas, such as majorcities, dead-spots may correspond to areas with no signal andembodiments can build up highly localized coverage maps. In oneembodiment, information can be collected where wireless signals areavailable on public transit systems. Users can rely on the collectedinformation and be able to select options including trip routing tomaximize signal availability. For example, a user may be willing to paya penalty in trip time in order to have a 3G signal available for theentire trip. Real-time location data for a user can be used to convert astatically planned trip (e.g., origin/path/destination) to a preciselist of concrete vehicles, times, or both associated with the trip.

Scheduled information can be matched with real-time data, and canprovide updates in the form of time increments to a schedule on aper-trip basis. Real-time data can include service alerts, scheduleupdates, location information (e.g., users and transit systems),passenger loads, video camera feeds, user GPS information, and otherdata. Raw data can be made available to websites and other datadistributors. Embodiments can provide integration for otherwise looselyconnected internal systems at an agency, and compensate when therelation of actual traffic versus scheduled traffic degrades over time.

XI. Further Examples

The following table is an example of a first trip joining scenario:

Time Marcus's Trip Phil's Trip Any time Searches for a trip from Abefore trip to B and decides on a route using public transit Any timeSends itinerary to Phil Receives itinerary from at/before trip Marcus11:57 Gets on Bus 94 from Phil's phone knows that Hallenbad Oerlikon.Marcus has started the trip and so calculates the actual trips Marcuswill be on from the itinerary and the information we have on schedulesand current time. 12:00 Arrives at Bahnhof Oerlikon 12:04 Phil isalerted that he should leave the office in 5 minutes in order to catchthe same train as Marcus 12:07 Takes the S16 from Bahnhof Oerlikontowards Bahnhof Tiefenbrunnen. 12:09 Phil is alerted that he shouldleave the office now in order to catch the same train as Marcus. Heleaves the office. 12:15 Passes through Zurich Gets on the S16 at ZurichHauptbahnhof on the train. Huptbahnhof towards Meets Phil on the train.Bahnhof Tiefenbrunnen. Meets Marcus on the train. 12:20 Phil and Marcusarrive Phil and Marcus arrive together at Bahnhof together at BahnhofTiefenbrunnen. Tiefenbrunnen.

The following are examples illustrating trip joining, and otherfeatures:

1. Morning Commute: Marcus lives near Altersheim, Zurich. Route to work:Bus 140 from Altersheim to Langnau then the S4 from Langnau to ZurichHB.

Marcus gets up and receives an alert on his phone that the bus to thetrain station is cancelled. Since it is only a short walk to the train,he can just leave a bit earlier and still catch the train.

Once Marcus arrives at Langnau, he gets on the train. There has been anaccident up ahead. Accordingly, he receives an alert that the train isnot going to be able to reach Zurich HB. Rather than wait to get closeto the destination and be stuck, his phone informs him to exit the trainthree stops early and take a tram instead.

Marcus arrives at work on time, despite the cancellations and delays.

2. Lunch: Marcus's friend, Phil, calls him about a new restaurant andsuggests they meet there for lunch. Phil sends his itinerary to Marcusand he agrees to join Phil on his journey to the restaurant.

Phil lives in Oerlikon and takes a bus to reach his local train station.As soon as he starts his trip to the restaurant Marcus's phone keepstrack of Phil's journey and informs him when to leave the office. Philchanges onto the S6 to reach the restaurant at Bahnhof Tiefenbrunnen.Marcus has live information on when the train will pass Zurich HB, nearMarcus's work. Marcus is alerted when to start walking to the stationand which train and carriage to take so that Marcus and Phil meet on thetrain. They arrive at the restaurant together.

Marcus's phone knows when his first meeting of the afternoon is andalerts him when he needs to take the train back to work. He doesn'twaste time waiting at the stop and arrives on time.

3. Evening: After work Marcus wants to meet his girlfriend at Zurich HB,ready to go for a concert in Winterthur. His phone warns him that thenext train about to arrive is full of people, but there is another onein 10 minutes that should be quieter. Since they are not in a rush andwould enjoy a more comfortable ride, they wait for the next train, wherethere are plenty of seats. Once they arrive in Winterthur, they take thebus to the concert. Since neither of them are familiar with the busesthere, they panic and think they have taken the bus in the wrongdirection, but fortunately Marcus can check his phone and determinewhich bus he is on from the location. Marcus can confirm they took theright one.

After enjoying the concert they head back to Zurich. It starts raining,so Marcus's phone directs them to a bus stop with a shelter nearby. Bothof them are tired after a long day and fall asleep on the train.Fortunately, Marcus's phone knows when they are about to reach thestation and an alarm sounds to wake them up.

XII. Conclusion

The Summary and Abstract sections may set forth one or more but not allexemplary embodiments as contemplated by the inventors, and thus, arenot intended to limit the present disclosure and the appended claims inany way.

The present disclosure has been described above with the aid offunctional building blocks illustrating the implementation of specifiedfunctions and relationships thereof. The boundaries of these functionalbuilding blocks have been arbitrarily defined herein for the convenienceof the description. Alternate boundaries can be defined so long as thespecified functions and relationships thereof are appropriatelyperformed.

The foregoing description of the specific embodiments will so fullyreveal the general nature of the present disclosure that others can, byapplying knowledge within the skill of the art, readily modify and/oradapt for various applications such specific embodiments, without undueexperimentation, without departing from the general concept of thepresent disclosure. Therefore, such adaptations and modifications areintended to be within the meaning and range of equivalents of thedisclosed embodiments, based on the teaching and guidance presentedherein. It is to be understood that the phraseology or terminologyherein is for the purpose of description and not of limitation, suchthat the terminology or phraseology of the present specification is tobe interpreted by the skilled artisan in light of the teachings andguidance.

The breadth and scope of the present disclosure should not be limited byany of the above-described exemplary embodiments, but should be definedonly in accordance with the following claims and their equivalents.

The claims in the instant application are different than those of theparent application or other related applications. Arguments made in arelated application should not be read into the instant application.

1. A method of providing transportation information for a user,comprising: receiving user data associated with public transportationusage; receiving public transportation data including real-time publictransportation data; and generating scheduling information based on theuser data and real-time public transportation data.
 2. The method ofclaim 1, further comprising generating a user profile for a user basedon at least one of user locations, user movements, user transportationqueries, user routes, and user vehicles.
 3. The method of claim 2,further comprising generating the user profile based on temporal travelpatterns of the user.
 4. The method of claim 2, further comprisinggenerating the user profile based on locality travel patterns of theuser.
 5. The method of claim 2, wherein the scheduling informationincludes a ranking of public transportation data based on the userprofile and a location of the user, wherein the public transportationdata includes transportation stations, transportation lines, andavailable trips.
 6. The method of claim 2, further comprising:generating a cluster of public transportation route segments based onthe user data and the public transportation data; determining publictransportation route segments relevant to the user; and associating therelevant public transportation route segments with the user profile. 7.The method of claim 6, further comprising suggesting the relevant routesegments to the user.
 8. The method of claim 1, wherein the user dataincludes user location data associated with at least one ofbrowser-based location information, mobile computing device locationinformation, user location data including location, speed, route, andtime corresponding to known public transportation services, usercheck-in to vehicles, user association with public transportation entryport devices, user access of information associated with a routingsearch engine or public transportation information, and user providedlocation information including, home addresses, work addresses, anddesignated user locations.
 9. The method of claim 1, further comprising:detecting a discrepancy between user behavior and generated schedulinginformation; and adapting the scheduling information based on thedetected discrepancy.
 10. The method of claim 1, further comprisinggenerating an alert, based on the user data and public transportationdata.
 11. The method of claim 10, wherein the alert indicates that theuser has boarded a vehicle that does not fit the scheduling information.12. The method of claim 1, wherein the real-time transportation dataincludes real-time public transportation vehicle location information,further comprising identifying a vehicle associated with a user'slocation based on the user data and the public transportation data. 13.The method of claim 12, further comprising determining the user'slocation based on the vehicle identification and the real-time publictransportation vehicle location information.
 14. The method of claim 12,wherein generating an alert includes generating an alert based on thevehicle identification and the real-time public transportation vehiclelocation information indicating that the vehicle is approaching an areawith no signal for the user's mobile computing, device.
 15. The methodof claim 12, wherein generating an alert includes generating an alertbased on the vehicle identification and the real-time publictransportation vehicle location information indicating that the vehicleis approaching the user's stop associated with the schedulinginformation.
 16. The method of claim 12, wherein generating an alertincludes generating an alert based on the vehicle identification and thereal-time public transportation vehicle location information indicatingthat the user is going to miss a connection indicated in the schedulinginformation.
 17. The method of claim 12, wherein generating an alertincludes generating an alert based on the vehicle identification and thereal-time public transportation vehicle location information indicatingprogress of the identified vehicle associated with the schedulinginformation.
 18. The method of claim 12, wherein generating an alertincludes generating an alert based on the vehicle identification and thereal-time public transportation vehicle location information indicatingthat a problem has occurred along a path of the identified vehicleassociated with the scheduling information.
 19. A system comprising: aprofile creator configured to receive user data associated with publictransportation usage; a rider analyzer configured to receive publictransportation data including real-time public transportation data; anda routing engine implemented on a computing device and configured togenerate scheduling information based on the user data and real-timepublic transportation data.
 20. The system of claim 19, furthercomprising an alert generator configured to generate an alert based onthe real-time public transportation data and user data.
 21. An apparatuscomprising at least one non-transitory computer readable storage mediumencoding instructions thereon that, in response to execution by acomputing device, cause the computing device to perform operationscomprising: receiving user data associated with public transportationusage; receiving public transportation data including real-time publictransportation data; and generating scheduling information based on theuser data and real-time public transportation data.
 22. The apparatus ofclaim 21, the operations further comprising generating an alert based onthe real-time public transportation data and user data.